Sysplex (multiprocessor cluster-based) enabled infrastructures are utilized extensively for workflow of client applications. For example, they are utilized in automatic teller machine (ATM) transactions. It has been found that some banking customers have experienced significant operational issues when accessing data in such an infrastructure.
Any customer who has a sysplex-enabled infrastructure that uses a web application server, such as WebSphere, with a TCP/IP gateway (for example, IMS Connect) to access a database and sends their asynchronous transactions using dedicated persistent socket will receive a duplicate client ID problem. When the duplicate socket ID problem is generated, the transaction request that was sent will either hang, return an error message, or become lost. This is a severe problem because the customer's clients potentially will be left standing at an ATM machine waiting for a transaction that cannot be completed.
To describe these issues in more detail, refer now to the following description in conjunction with the accompanying figures. There are two scenarios in which the duplicate socket ID problem is generated.
FIG. 1 is a first embodiment of a conventional sysplex enabled infrastructure 10. The infrastructure 10 includes a sysplex distributer 12, two plurality application servers 14a-14n, a TCP/IP gateway 16 and a database system 17. The sysplex distributor 12 assigns a transaction request to a specific application server 14a-14n. Each application server 14a-14n includes a resource adapter 19a-19n. The first scenario is if the customer is in a multi-thread environment where the sysplex distributor (SD) 12 is managing multiple application servers 14a-14n. The purpose of the SD 12 is to manage and balance the workflow and increase server availability.
In this scenario, when an ATM machine 20 whose client ID is ATM1 sends an asynchronous transaction request, the sysplex distributor 12 assigns the transaction request to a specific server, for example, server 14a. The resource adapter 19a inside server 14a sends the transaction request to the database system 17 through a TCP/IP gateway system 16 using a dedicated persistent socket connection 21a. The dedicated persistent socket connection 21 must have a unique client ID, which in this case is ATM1. The client ID identifies the client application and allows only transaction requests from that client application to reuse the socket connection; hence it is a dedicated persistent socket. The transaction is completed when the response is returned to the ATM machine 20 and the interaction ends. However, because the socket 21a is a dedicated persistent socket, that connection from the server 14a to the TCP/IP gateway 16 stays open to be reused for the next transaction request from the ATM1 client application.
If another transaction request is sent by the same ATM machine 20 (whose client ID is ATM1) and the sysplex distributor 12 assigns the request to another web application server, for example application server 14b, the same process occurs. The resource adapter 19b inside application server 14b sends the transaction to database system 17 through the TCP/IP gateway 16 using the persistent socket connection 21b that contains the ATM1 client ID. However, the server 14a already has the ATM1 client ID socket connection open.
The gateway 16 recognizes that the socket connection 21a is open on server 14a and rejects the transaction request from server 14n with the message that it is a duplicated client ID even though the interaction on server 14a had completed. Because each dedicated persistent socket connection 14 must have its own unique client ID and the ATM machine 20 only has one ID, a duplicate socket ID error is generated. If multiple transaction requests are sent through the ATM1 machine 20 and distributed to different servers by the SD 12, many transactions will be rejected due to the duplicate ID problem.
Another scenario that generates the duplicated client ID problem is if the customer uses one application server and creates multiple servant regions within that server. Similar to the SD, the server acts like a workflow manager and directs transaction requests to specific servant regions to increase server availability. The following figure illustrates the process flow in which the duplicated socket ID problem is generated.
FIG. 2 is a second embodiment of a conventional sysplex enabled infrastructure 10′. The infrastructure 10′ includes a sysplex distributor 12′, an application server 14′, a TCP/IP gateway 16″ and a database system 17′. SD 12 assigns a transaction request to servant regions 30a-30n within the server 14′.
In the second scenario, a transaction request is sent to a servant region 30a which is received by database system 17′. A response is returned to the ATM 20′ and the interaction is completed. However, when the ATM 20′ sends in a second request and that request is directed to the servant region 30b, a duplicated socket ID problem is generated because a socket connection 21a′ with the client ID ATM1 is open in servant region 30a. As a result, the TCP/IP gateway 16′ rejects a message and the transaction request fails.
This problem increases exponentially if any customer has a sysplex structure where there are multiple application servers and each of those servers have multiple servant regions.
To address this problem, a customer can choose to use shareable persistent socket for sending asynchronous transactions to the application server to bypass the duplicate client ID problem. However, with this method, the customers must rewrite their client applications and not specify a customer-specified client ID to an application server. This eliminates the capability of using the customer-specified client ID for tracking, security, and maintenance purposes.
Also, because the legacy application running in the database in most cases uses the customer-specified client ID to identify the client application for unsolicited messages, the legacy application must then be re-written for this solution. Furthermore, with this solution, using the sharable persistent socket increases the number of IMS output queues, thus impacting IMS storage requirements.
Accordingly, what is needed is a system and method that overcomes the above-described operational issues. The system and method should be cost effective, easily implemented and adaptable to web-enabled database systems. The present invention addresses such a need.